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(54) Apparatus and method for processing servlets 



(57) A method and apparatus (or operating a local 
server computer of a client-server network includes a 
technique to receive a request from a client computer of 
the client-server network. A determination is made 
whether the request requires dynamically generated in- 



formation from a servlet object of the client-sen/er net- 
work. If so. a specified sen/let object corresponding to 
the request may be uploaded from a remote server com- 
puter of the client-server network. The specified servlet 
object IS then executed to obtain dynamically generated 
information corresponding to the request. 
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Description i 

Brief Descnotion of the Invenlipn \*. 

, .^^^^ 

This invention relates aeneraliy to exchanging information in a client^server comouior enviranmont .More partic- 
ularly this invention relates :o an improved technique lor responcmg to information rccuosts at a server com.puier 

Backc.'oung of the invention " 

Ciient-server computer nciworks are well known The most prominent example of a chont-sorvor computer network 
iS the World Wide Web of computers In a clieni-sorvor computer network, a server computer receives a request for 
information from a client computer. Wob server software operating on the server computer typically retrieves the re- 
quested inform.ation from a file stored on a permanent storage device and transmits the file over the network to the 
client computer that requested the information. The web server software is generally not written using an object oriented 
programming language. Thus, tt is not easily extended to provide new functionality Given the dynamic nature of today's 
software marketplace, a product's lack of flexibility and extcndibility can seriously hinder the marketability of the product 
Current web server software can generate a file dynamically m response to a request from a client computer 
Typically, the web server receives the request and then forks a Common Gateway Interface (CGI) process to dynam- 
ically create the file Once the file has been created, the web server software transmits the file back to the client 
computer, Unfonunately. it is computationally expensive to fork a process each time dynamic information needs to be 
generated 

In view of the foregoing, it would be highly desirable to provide a weo server which dynamically generates infor- 
mation in response to a client computer request, but which does not incur a process start-up expense while generating 
the dynamic information Further it woMd_b.eJiighly_desirableJO-prov.ide-an-oo|ect-orjented-web-server-enviro 
that IS flexible and extendible 

Summary of the Invention 

The invention includes a method and apparatus for operating a local server computer of a client-server network. 
The invention includes a technique to receive a request from a client computer of the client-server network. A deter- 
mination is m.ade whether the request requires dynamically generated information from a servlet object of the client- 
server network. If so. a specified servlet object corresponding to the request may be uploaded from a remote server 
computer of the client-server network The specified servlet object is then executed to obtain dynamically generated 
information corresponding to the request. 

The servlet objects of the invention provide an object oriented web server environment which is flexible and ex- 
tendible. The client-server network of the invention is populated with the servlet objects The servlet objects operate 
in a continual loop until invoked Thus there is no startup overhead associated with execution of the sen/let objects 
By obsen/ing a common applications program interface, the servlet objects can run m any sen/er environment, A feature 
of the invention allows untrusted servlet objects to bo executed in a secure area, with the dynamically generated 
information being passed from the secure area into the remaining server environment. 

Brief Description of the Drawings 

Examples of the invention will now be described in conjunction with the accompanying drawings, in which: 
FIGURE 1 illustrates a client-server computer network in accordance with an embodiment of the invention, 
FIGURE 2 is a simplified illustration of the interactions between a web server and the servlets, 
FIGURE 3 is a simplified illustration of the interactions between a web server and a sen/let loaded from an external 

server, 

FIGURE 4 illustrates processing steps associated with a servlet processing routine 
FIGURE 5 illustrates processing steps associated with a servlet processing routine 
Like reference numerals refer to corresponding parts throughout the several views of the drawings 

Detailed Description of the Invention 

55 Figure 1 illustrates a client-server computer network 20. 

The network 20 includes at least one client computer 22 and at least one server computer 24. The client computer 
22 and the server computer 24 are connected by a transmission channel 25. which may be any wire or wireless trans- 
mission channel. 
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The client computer 22 is a standard computer including a Central Processing Unit (CPU) 30 connectea lo a 
memory (primary and/or seconaary) 32. The memory 32 stores a numoer ot computer programs, tnciucmg a "browser" 
34, As known in the art. a browser is used to communicate with remote server computers 24 and lo visually present 
the information received from such computers. The client computer 22 establishes network communications througn 

5 a standard network connection device 36. 

The server computer 24 includes standard server computer components, including a network connection oevice 
40, a CPU 42. and a memory (pnmarv and/or secondary) 44 The memory 44 stores a set ol computer programs to 
implement the processing associated with the invention The memory 44 stores a web server 46 The web server 46 
may be of the type known tn the art. which is modified to include the additional programs snown in rtgure 1 That is 

'0 in an embodiment of the invention, a standard web server 46 is modihed to include a server acceptor thread 45. a 
connection queue 50. a pool administrator 52. a thread pool 54. servlets 56. a serviet map 55, a security administrator 
60. and boundary servlets 62. 

Figure 2 is a simplified illustration of a server computer 24A constructed in accordance with an em.bodiment of the 
invention. The figure shows a web server 46 interacting with a set of servlets 56A-56N. In particular the web server 

'5 46 interacts with the servlets through an application program interface (API), As indicated in Figure 1. the web server 
46 and the servlets 56 are stored in memory 44 The web server 46 may be standard web server software that is 
modified to include the (uncitonaliiy described herein. Each serviet 56 is a piece of software code which is used to 
dynamically generate information. Each serviet 56 is an instantiated software object waiting to be invoked. Once it is 
invoked, it dynamically generates information. Note that this technique of dynamically generating information is distinct 

20 from the typical process of fetching static information from a permanent storage device. The technique of the invention 
is similar to a CGI script in the sense that it dynamically generates information. However, unlike a CGI script, a serviet 
object of the present invention is instantiated at server stan-up. Thus, the serviet can be thought of as operating in a 
continual loop waiting to be executed Observe that after instantiation there is no computational start-up expense when 
the serviet is called. 

25 Figure 3 is a general illustration demonstrating additional features of the invention. Figure 3 illustrates a local server 

computer 24A which receives a request from a client computer (not shown) over transmission channel 26. The web 
server 46 determines that dynamically generated information from a serviet object is required. In this case, the servlel 
object IS not initially on the local server computer 24A. thus it is uploaded by the local server computer 24A from a 
remote server computer 24B using communication link 26. In the example of Figure 3. serviet 56P is passed from the 
remote sen/er computer 24B to the local server computer 24A. 

Figure 3 illustrates another feature of the invention. In particular, it illustrates that the uploaded serviet 56P is 
executed in a security area 57 of the local server computer 24A After execution, the results are passed to a boundary 
servlel 60 in the remaining portion of the local server computer 24A. This security feature allows untrusted servlets to 
be safely executed. 

35 The foregoing discussion provides a general description of the features and benefits of the invention. Attention 

now turns to a more detailed description of these features and benefits. The left side of Figure 4 illustrates processing 
steps associated with an embodiment cf the invention. The right side of Figure 4 illustrates program components that 
may be used to execute these operations. 

The first processing step shown in Figure 4 is to determine whether a new request has been received (step 70). 

■JO As indicated above, a request is a request for information from a client computer 22 to a server computer 24. The 
operation of a client computer 22 requesting information from a server computer 24 is well known. It is typically per- 
formed using a Uniform Resource Locator or URL. A URL specifies a computer and a file. A typical URL is http7/SU/ 
123. This URL is an instruction lo retrieve the file ■123" from the State University computer "SU" using the Hypertext 
Transfer Protocol "HTTP". 

-^5 As shown in Figure 4. a server acceptor thread 48 is used lo process each new request. Preferably, the invention 

is implemented as a connection-oriented web server with a server acceptor thread that continually loops while accepting 
requests. Once a request is received, it dispatches the request to a connection queue (step 72). As shown in Figure 
1. the connection queue 50 is formed in the memory of the local server computer 24. 

If no new request is received, then a check is made lo determine whether the queue is empty (step 71). If the 

50 queue is not empty or a new request has been received, processing proceeds to step 74. Step 74 entails thread pool 
administration operations, which are executed by a pool administrator 52. Figure 1 illustrates a thread pool 54. The 
thread pool 54 is a pool of threads that are used for request processing. Individual threads fetch and process requests 
from the connection queue 50. The pool administrator 52 operates lo ensure that there is a thread for each request in 
the connection queue 50. The pool administrator 52 creates or forks additional threads to handle new requests in the 

55 connection queue 50, If a maximum number ol threads is reached, the pool administrator 52 blocks new requests from 
entering the connection queue 50. In such a case, the server computer does not receive new requests. On the other 
hand, if a thread has been waiting more than a predetermined period of time for a request from the connection queue 
50. then the pool administrator 60 will destroy it. Preferably, a new handler thread is created using the buffer space of 
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a destroyec handler thread In other words the invention is preferably impierr.eniec! by using a soecilic outfer .Ti^,-nor\' 
soace for a thread When a thread is destroyed, the buffer memory scace is cleared but it is assigned to a n-".v •■•^r'ca- 
By reusing allocated memory in this manner this embodiment of the invention minimizes the am'ount'of memory Jsed 
by the system, especially when compared to systems which allocate and deallocate memory on a per reaues; oasis 
Alter the thread pool administration operations are perlormed (step 7J) a thread retrieves a recuest from ih« 
connection queue (step 75) The thread then maps the request to a servlet name (steo 75) The servlel may be specified 
by a URL in which case the mapping process, is direct. On ihe-other hand some translation process-may dg roqu.ro- 
10 Identify which sen/let will be able to service tho request The trapping operation may bo perlormed m one of tne 
following ways A server administrator moy specify that some kinds of client requests always map to a pamcuiar servici 
ror example, one which talks to a particular database A server admmistraior may specify that oan of Ihe ci.ont request 
IS the name of the servlet. as lound in an administered servlets directory Ai many sites, that directory would bo shared 
between servers which share the load ol processing for the site's clients. Some servers may bo able to automatically 
invoke sen/lets to filter the output of other sorvleis. based on their administrative configuration For examolo particular 
types of sen/let output may trigger post-processing by other servlets. perhaps to perform format conversions Properly 
authorized clients may specify the sen/lei to be invoked, without admimstraiivo intervention 

Security operations may also be perlormed by the thread (step 80) A security administrator SO may be used to 
ideniily trusted and untrusted classes ol servlets The decision to trust a servlel may be established by a set o( rules 
associated with the security administrator 60 For example, the secunty administrator 60 may decide to trust all local 
servlets and mistrust all uploaded network servlets Untrusted servlets are then executed in the security area 57 as 
Shown in Figure 3 The security administrator 60 may also be used to determine if the servlet is authorized to perform 
predetermined risky operations Security information of this type may be stored in the thread 

JAVA sen/lets in accordance with the invention provide strong security policy support This is because all JAVA 
environments provide a Security Manger which can be used to control whether actions such as network or file access 

_ar.eJo-be.perm.ited^By-de(ault-all-servleis-are-unirusied-and-are-not-allowe-dToTDeTf orm operations such as acce^ 
network services or local dies. However, servlets -built into" the server, or servlets which have been digitally siqned as 
ihey were put into JAVA Archive files may be trusted and granted more permissions by the security manager A digital 
signature on executable code indicates that the organization which signed ihe code "vouches for ,f in some sense' 
Such signatures can't support accountability by themselves, but they do indicate a degree ol assurance that may be 
placed on use of that code. For example, a particular signature from an MIS organization might be required on all code 
which ,s granted general access to network services within a corporate intranet. That signature might only be used on 
code which is strongly believed not to violate particular security policies Extension APIs ,n other languages such as 
C or scripting languages, can't support such fine grained access controls even if they do allow digital signatures lor 

After secunty operations are performed (step 80), the thread is dispatched (step 82 of Figure S) The dispatch 
operation entails invoking a servlet so that it generates the requested dynamic information The dispatch operation is 
one of two types A decision is made to determine whether the sen/let Is local (step 84), If the servlel is local then the 
local sen/let is executed (step 66). This results in the generation of dynamic information that is then processed by the 
web server 4o in a standard manner The web server 46 typically passes Ihe information back to the client computer 
using known techniques. The exchange of information between a servlet and the web sen/er 46 is achieved through 
an application program interface, which is described below. 

whoihrif""!' ^ '^""^'^ '^^"^ 248 (step 88). A decision is then made regarding 

whethe the uploaded sen/let is safe (step 90). Recall that the security operation step resulted in the thread acquiring 
inlorma .00 regarding security parameters tor servlets. If there are no secunly problems associated with the uploaded 
servie . then .t is executed locally (step 92). On the other hand, if a security problem is identified, then the servlet is 
ari fln'o«,TK ''f ^y"^^'=^"y generated results are passed to the non-secunty 

?h! ?,« of cf K TT'^ ""^^ "^'^ """"^^^ -^^y implemented through 

the use ol stubs and subcontracts or through other -fire wair techniques known in the art After the sen/let is executed 
processing returns to step 70 of Figure 4. 

of thrsZrrr ?' T '""y ^^^^"''ed. Attention now turns to a more particular discussion 

tZVr . ' '^''^ '^^ '"^^^'-^^ and an embodiment of the appl.cation program 

obSu '°h"'!I'°" "^^ °'"«'=>^ Objects are software 

obiecls that are used to dynamically generate information. They are tnstan.iated objects that sit in a loop waiting to bl 

Thluhe jS^.l!lmm'' implemented as ob.ect bytecodes in the JAVA- programming language. It is well known 
ZaLZZ ^'^'^ 'o '"^P'^-^^"' -aPP'e's- on a client computer An -applet" is executable 

JAVA obiect bytecodes that are used to generate a graphical display on a client computer The servlets embodyinq the 
present invention are executed on the sen/er side and do not have graphical content 

nr.H^.r'^'^'J^ '^'''f^"^ instantiated on server startup. In the alternative. Ihe servlet may be instantiated under a 
predetermined set of conditions or by client invocation. The servlet may be Instantiated and executed by using its URL 
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(e g . httpy/hosl'' < servlel URL>). The http protocol suppons the passing of arguments, thus arguments may be passec 
to the servlet {e g hup. //host/ < servlol URL>'^< arguments >), The prcpeaies ooiect ts a JAVA prcgram.ming lar.guace 
properties class which comprises a set of "name value" parrs A system acmmistrator can pass arguments to an in- 
stantiated HitpServlet object through the properties obiect In this way (he system administrator can 'customize" an 
Http5erv!et for a particular server at a particular site For example the system administrator can pass the Httpser^le: 
object site specific information about the network location of a database wmch stores documents mat will bo roquostoc 
by client processes across the neiwork or the amount of memory available m system buffers wmch will bo used lor 
processing the server administrator. 

Once instantiated, a servtet loops until the server is shut off or a destroy method is called on the servlet by the 
server Since the servlet operates in a continual loop as it watts for requests to act upon the server computer avoids 
the overhead of creating and destroying the servlet between requests to the servlet. In addition, koopmc sorvlots aiivo 
between requests allows servlets to pass data and communicate amongst themselves For example servicis can 
maintain data about a user between sessions by the user This data can bo shared among different sorviets m order 
to customize a working environment within which the user works If servlets were created and destroyed on a per 
request basis, it would be much more difficult, if not practically impossible, for a servlet to understand the environment 
within which it runs and utilize this knowledge to provide improved processing capabilities Tne server computer can 
call a destroy method on the servlet when some resource limit m terms of time, memory, etc is reached 

The servlet application program interface (API) establishes a standard for interfacing servlets with information 
servers, such as web servers The servlet API contains methods for imttaiizing a servlet. processing the request, getting 
servlet information, and destroying the servlet. The servlet API allows platform independent servlets An example 
servlet interface is as follows 



Sen/let interface: 
interface HttpServlet { 

Initialize (ServleiContexi, ScrvcrPropcrties); 

Service(HttpRequest, HttpResponse); 

Destroy 0; 

) 

The server computer passes objects that implement the "HitpRequesf. while the servlet returns an "HttpResponse" 
object. The "ServletContexi" interface is used to exchange information with the server environment. Some of the meth- 
ods on the "ServletContext" object arc "GetserverO" and 'GetServletsO'. 'GetServer" returns a pointer to the parent 
sen/er within which the instantiated Httpservlet runs. Using this pointer, the HitpSen/lel object can find out information 
about its parent server. The "GetServlef method returns pointers to the servlets running on the parent server. The 
"ServerFroperties" interface is used to exchange information regarding specific server properties established by a 
server administrator 

Servlets support the familiar programming model of accepting requests and generating responses. The following 
is a simple servlet defining a single method called "service" 
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import java.servlet.*; 

public class MyServlet extends GenericServlet { 
public void service ( 

ServletRequest request, 
ServletResponse response 
) throws ServletException, lOException 

{ 
} 

) 

The service method is provided with Request and Response parameters. These parameters encapsulate the data sent 
by the client thereby allowing servlets to report status information, such as errors Serviets normally retrieve most of 
their parameters through an input stream and send their responses usin g an output strea m 

ServletlnputStream in = request. getlnputStream (): 
ServiotOutputStream out = response. getOutputStream (): 

These input and output streams may be used with data in whatever format is appropriate. For example an applet and 
serviet might exchange data using object serialization, HTML, or any number of imago formats. 

Since sen/lets are JAVA objects, they have instance-specific data. This means that in effect servlets are independ- 
ent applications running within servers, without needing the complexity of additional classes (which are required by 
some alternative server extension APIs), Servlets have access to some servlei-specific configuration data at mttiah- 
zation ume. This allows different instances of the same serviet class to be initialized with different data, and be managed 
as differently named servlets. The data provided at initialization time includes an area where each instance keeps its 
persistent instance-specific state. 

Budding upon the previous simple serviet examples, the following program code is an example of a serviet that is 
used to send Hypeaext Markup Language (HTML) text when it is invoked: 
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public class SimpleServlet extends GenericServlet { 
public void service(Sep/letRequesl req, ServleiResponse res) 
throws ServlelException, lOExccpiion 

{• 

res.selConteniTypeC'textyhtml"); 

PrintWriter out = new PrintWriter(res.getOuipuiStrcam()); 

out.printlnC' <HEAD> < TITLE > SimpleServlet Output 
< /TITLE > </HEAD> <BODY>"); 

out.printlnC < hi > SimpleServlet Output </hl>"); 
out.printlnC <P>This is output from SimpleServlet."); 
out.println(*'</BODY>"); 
out.flushQ; 

} 

public String getServletlnfoQ { 

return "A simple servlet"; 

} 

} 

The following program code is an example of a servtet that uses the finger protocol to query information about 
users on specified host computers. The query string parameters < tt > user < /tt >. < tt > hosts < /tl >. and < tt > verbose 

< /tt > can be used to specify the user and hosts to query The parameter <tt> user </tt> is the user name. <tt> hosts 

< /tt > is a comma-separated list of host names to query, and <tt> verbose <At>. if specified, will cause verbose output 
to be generated. For example. <pre> htlp /goa/finger.htmt?user=dac&hosts=eno.doppio&verbose=yes </pre> wilt re- 
quest full information about user 'dac" on both hosts 'eno" and "doppio". 
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public 

class FingerServlet extends GenericServlet { 

* Port number for finger daemon. 
*/ 

static final int FINGER_PORT = 79; • 
Handles a single finger request from the client. 

*/ 

public void service(ScrvletRequest req, ServletResponse res) 
throws ServleiException, lOException 

{ 

String user = req.getParameter("user"); 
String hosts = req.getParameterC'hosts"); 
String verbose = req.getParameter("verbose"); 
res. setConten tTy pe( " lex t/ html" ) ; 



PrintStream out = new PrintStream(res.getOutputStreamO); 
out. println(" < html > "); 

out. printing < head > < title > Finger Servlet < /title > < /head > 

out.println("<body>"); 

out.printlnC < h2 > Finger results: < /h2 > "); 

outprintln(" <pre> "); 

if (hosts == null) { 

finger(out, user, null, "yes",equalsIgnoreCase(verbose)); 
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} else { 

StringTokenizer si = new StringTokenizer(hosts, 
while (st.hasMoreTokcnsQ) { 

Siring host = sl.ncxtTokenQ; 

out.printlnd" + host -f "]"): 

try { 

fingcr(out, user, host. 

**yes".equalsIgnoreCasc(vcrbose)); 

} catch (lOException c) { 
out.println(c); 

} 

out.printlnO; 

} 

} 

out.printlnC </pre>**); 
out.println("</body> </html>"); 

} 

/* 

* Sends finger output for a user and host to the specified output 

* stream, 
*/ 

void finger(OutputStream out, String user, String host, boolean verbose) 
throws lOException 

{ 

// open connection to finger daemon 
Socket s; 

if (host = = null) { 

s = new Socket(InetAddress.getLocalHost(), 

FINGER^PORT); 

} else { 

s = new Socket(host, FINGER_PORT); 

} 

// send finger command 
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PrintStream ps = new PrintStream(s.getOutputStream()); 
if (verbose) { 

ps.print(VW^); 

} ^ . 

if (user ! = null) ( 
ps.print(user); 

} 

ps.print("\r\n"); 
ps.flushO; 

// copy results to output stream 
InputStream in = s.getlnputStreamQ; 
byte[] buf = new byte [5121; 
int len; 

whiie-((ien-=-in7read(l)ufrOrbuf7length))-!-=— 1"^^ 

out.write(buf, 0, len); 

} 

s.closeO; 

} 

} 

Those skilied tn the art will appreciate that servfets which are being used with the HTTP protocol may support any 
HTTP method, including GET. POST HEAD, and more. They may redirect requests toother locations and send HTTP- 
specific error messages. They can get access to parameters which were passed through standard HTML forms, in- 
cluding the HTTP method to be performed and the URI. which identifies the destination of the request. 

As indicated above, one of the biggest performance features of servlels is that they do not require creation of a 
new process for each request. In most environments, many servlels run in parallel within the same process as the 
server. When used in such environments with HTTP servlels provide compelling performance advantages over both 
the CGI approach and the Fast-CGI approach. This is because servlets have a small computational expense during 
thread context switches. Since in most environments servlels can handle many client requests each lime they are 
initialized, the cost of the initialization is spread over many methods. All the client requests to that service have the 
opportunity to share data and communications resources, benefitting more strongly from system caches. 

Those skilled in the art will appreciate that the servlels embodying the invention can be used to dynamically extends 
Java-enabled sen/ers. The servlets provide a general framework for sen/tces built using the request-response para- 
digm. The servlets can provide secure web-based access to data which is presented using HTIVtL web pages and they 
can be used for interactively viewing or modifying that data using dynamic web page generation techniques. 

The servlels embodying the invention may be used to provide customized multiuser sen/ices for customer bases. 
The servlets are also flexible enough to support standardized services, such as serving static web pages through the 
HTTP (or HTTPS) protocols, and proxying services. Since they are used for dynamic extensibility, they may be used 
in a plug-in style, supporting facilities such as search engines and semi<ustom applications, such as web-based order 
entry or inventory systems. 

Although the servlets are preferably written in JAVA, the sen/let clients may be written in any language. When 
servlets are used in the middle tiers of distributed application systems, they can in turn be clients to other services, 
written in any language. 
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Those skilled m the art will appreciate that servlets may be used m several moaes. The basic mode is at the core 
of a request/response protocol, in addition sen/lets may de specialized to support protocols sucn as HTTP in HTTP 
based applications, servlets are portable, complete, and much more efficieni replacement for CGI based extensions 
Also in HTTP applications servlets may be used with HTML server side includes to dynamically generate part of a 
s web document. 

The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough under- 
standing of examples of the invention However, it will bo apparent to one skilled in the an that the specific details are 
not required m order to practice other examples of the invention. In other instances, well know circuits and devices are 
shown in olock diagram form in order to avoid unnecessary distraction from the underlying principles Thus, the fore- 
^0 going descriptions of specific embodiments of the present invention are presented for purposes of illustration and 
description 



Claims 

;5 

1 . A method executed by a local server computer under the control of a program, said local server computer including 
a memory for storing said program said local server computer forming a portion of a client-server network, said 
method comprising the steps of: 

20 receiving a request from a client computer of said client-server network; 

determining that said request requires dynamically generated information from a servlet objec! of said client- 
server network; 

uploading from a remote server computer of said client-server network a specified servlei object corresponding 
to said request: and 

25 executing said specified servlet object to obtain dynamically generated information corresponding to said re- 

quest. 

2. The method of claim l further comprising the step of passing dynamically generated information from said specified 
servlet object to a web server operating on said local server computer, said passing step being facilitated with an 

^0 application program interface. 

3. The method of claim 2 wherein said application programming interface specifies techniques for performing at least 
one of the following operations: initializing a servlet object, executing a servlet object, and destroying a servlei 
object. 

35 

4. The method of claim 2 wherein said specified servlei object and said application program interface are specified 
as ob)ecl bytecodes in the JAVA programming language 

5. The method of claim 2 furlher comprising the step of sending said dynamically generaied information from said 
JO web server to said client computer 

6. The method of claim 1 wherein said executing step includes the steps o( 

executing said specified servlet in a security area of said local server computer: and 
-=5 passing said dynamically generaied information from said securiiy area to a non-security area of said local 

server computer. 

7. The method of claim 1 wherein said local server computer stores a plurality of servlet objects, each of said servlei 
objects continuously operating until invoked in response to a specified request from a clienl computer. 



so 



55 



8. The method of claim 7 wherein said plurality of servlet objects pass data lo one another. 

9. The method of claim 7 wherein said selected servlet objects of said plurality of servlet objects are instantiated at 
the start-up ol said local server computer. 

10. The method of claim 7 wherein selected servlei objects of said plurality of servlet objects are instantialed in re- 
sponse lo a demand from said client computer 
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11. The method of claim 7 wherein seiecEec serviet objects of saic plurality of serviet coiects are mslar.tiaied m re- 
sponse to an activaiea serviet URL 

1 2. The method of claim 1 1 wherein saia serviet URL includes arguments 

1 3. The method of claim 1 wherein said receiving step includes the siep of storing satd rGGuost m a connection aueuo 

1 4. The method of claim 1 3 wherein said determining step includes the step of selecting a handler thread from a pool 
of handler threads to execute satd determining step 

1 5. The method of claim 1 4 further comprising the step of operating said pool of handler threads by seioctivciy creating 
a new handler thread and destroying an old handler thread 

16. The method of claim 15 wherein said operating step includes the step of reusing a buffer memory space of said 
old handler thread for said new handler thread 

17. A computer readable memory that can be used to direct a server computer of a client-server computer network to 
function in a specified manner, comprising' 

a first set of instructions to receive a request from a client computer of said client-server network: 

a second set of instructions to determine that said request requires dynamically generated tnlormation from 

a serviet object of said client-server network: 

a third set of instructions to upload from a remote server computer of said client-server network a specified 

serv.lei-objecLcor.r.esponding.to_said_r.equesL_ahd 

a fourth set of instructions to execute said specified serviet object to obtain dynamically generated information 
corresponding to said request 

18. The apparatus of claim 17 further comprising a fifth set of instructions to pass, through an application program 
interface dynamically generated information from said specified serviet object to a web server operating on said 
local server computer 

19. The apparatus of claim IS further comprising a sixth set of instructions to pass said dynamically generated infor- 
mation from satd web server to said client computer 

20. The apparatus of claim 17 further comprising a seventh set of instructions to store a plurality of serviet objects on 
said server computer each of said serviet objects continuously operating until invoked in response to a specified 
request from a client computer. 

21 . The apparatus of claim 20 wherein said seventh set of instructions include instructions to pass data between said 
plurality of serviet objects. 

22. A computer readable memory that can be used to direct a server computer of a client-server computer network to 
function in a specified manner, comprising: 

a first set of instructions to receive a request from a client computer of said client-server computer network: 
a second set of instructions to determine that said request requires dynamically generated information from 
a sen/let object of said server computer: 

a third set of instructions to execute said specified serviet object to obtain dynamically generated information 
corresponding to said request: and 

a fourth set of instructions to pass said dynamically generated information to said client computer 

23. The apparatus of claim 22 wherein said second set of instructions include instructions to interpret a serviet URL 
corresponding to said request. 

24. The apparatus of claim 22 wherein said second set of instructions include instructions to interpret a serviet URL 
with arguments. 

25. The apparatus of claim 22 further comprising a fifth set of instructions to store a plurality of sen/let objects on said 
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server computer, each of said servlei ob)ects continuously operating unti! invokea in response (oa specifiea request 
from a client computer. 

26. The apparatus of claim 20 wheretn said filth set of instructions include instructions to pass data between satd 
plurality of serviet ob|ects. 

27. A client-server computer network comprising: 

a client computer to generate a requosi: and 
a sen/er computer to 

determine thai said request requires dynamically generated information from a servloi object of satd server 
computer, 

execute said specified serviet obiect to obtain dynamically generated information corresponding lo said 
request, and 

pass said dynamically generated information to satd client computer 

28. The apparatus of claim 27 further comprising a remote server computer storing a set of servtct objects that can 
be passed to said server computer. 

29. The apparatus of claim 27 wherein said server computer stores a plurality of serviet objects, each of said serviet 
objects continuously operating until invoked in response to a specified request from said client computer. 

30. The apparatus of claim 29 wherein said plurality of serviet objects pass data between themselves. 
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